Telegram Group & Telegram Channel
سوال جالبی از من پرسیده شد جهت افزایش دانش شما عزیزان به اشتراک گذاشتیم ❤️

🤔 سوال توسط amirmohammad Fathollahi پرسیده شد:
من برای api gateway دنبال best practice هستم با ocelot
هرچی ویدیو میبینم صرفا در حد اینه route کنه
ولی راجع به معماری و هندل کردن چندین پروژه حرفی نزدن
اگه کسی منبع خوب یا سمپل کد میشناسه معرفی کنه ممنون میشم
توی معماریش چه کار هایی میکنن چه چیز هایی رو بهش میسپرن
آیا صرفا فقط برای reverse ازش استفاده میکنن یا rate limiting و authentication هم بهش میسپرن
بیشتر سوالم راجع به معماریش هست


💡 جواب:
در واقع API Gateway رو یا باید خودمون پیاده سازی کنیم یا از ابزارهایی مثل Kong استفاده کنیم.
اگر خودمون پیاده سازی کنیم طبیعتاً دسترسی کامل به همه چیز داریم ولی Kong مثلا بهمون یک Dashboardهم میده و شاید در یک سری جاها به اندازه یک API Gateway اختصاصی دست آدم باز نباشه.

حالا وقتی میخواهی خودت پیاده کنی Per Environment باید Config های Routing خودت‌رو داشته باشی یعنی روی Develop با Production باید Configهاشون فرق داشته باشه چونکه آدرس ها در Develop Local و Production قطعا متفاوت هست.
یکی از Best Practiceهایی که معمولا در API Gateway ها در نظر می‌گیرند Code Less می‌کنندش یعنی هیچ کدی داخلش نمی‌گذارند و واقعاً شبیه Gateway عمل میکنه، بدون هیچ Business Logic خاصی.

درباره Rate limit باید بهتون بگم که Trade-off زیاد دارد!
یک موضوع infrastructure ای هست یعنی در لایه Application پیاده نمیشه چون Bottleneck برنامه میشه و اگر مشکل داشته باشه میتونه برنامه بندازه یا کند کنه همچنین میتونه single point of failure باشه.
پیچیدگی Rate Limit زمانی هست که چندین Instance از برنامه ما بالا باشه به همین دلیل Application Layer جای خوبی نیست براش اما اگر برنامه شما اینقدر کوچک هست که یک Instance فقط از API Gateway دارد، بنظرم دوباره فکر کنید آیا واقعاً به microservice نیاز داشتید یا نه!
حالا فرض میکنیم که شما به API Gateway نیاز داشتید و Rate Limit هم قرار هست پیاده کنید بنظر من بهتره در لایه Application خودتون پیاده سازی بشه و اگر واقعاً یک چیز نیاز دارید که خیلی Global باشه و زیرساخت ندارید مثل تیم DevOps بنظرم API Gateway جای خوبی هست

اما در کیس Authentication خیلی Trade-off نداریم!
کنترل رو می‌سپارن به خود Application ها، همان‌طور که گفتم خیلی سعی میشه API Gatewayها Code Less باشن فرض کنیم سرویس A با مدل AModel احراز هویت میشه و سرویس B با مدل BModel و این میتونه در API Gateway پیچیدگی ایجاد کنه و از نظر Separation of Concerns باید API Gateway یک Gateway بمونه واقعاً
به این دلیل که Authentication میتونه خیلی پیچیدگی ایجاد کنه من حداقل ندیدم جایی احراز هویت رو روی Gateway پیاده کنند، ولی این کار نشدنی نیست.
در بعضی از مدل های احراز هویت نیاز هست که Token برای سرویس اصلی که Authentication رو پیاده سازی کرده ارسال بشه و اگر ما در API Gateway احراز هویت رو پیاده سازی کرده باشیم این میتونه باعث بشه API Gateway خودش گلوگاه باشه که درخواست‌ها رو کند کنه و وقتی کندی در سیستم میبینیم نمی‌دانیم سرویس واقعاً مشکل دارد یا API Gateway

اگر نظری دارین در کامنت ها برام بنویسید 👇
Channel: @hasanxdev
Please open Telegram to view this post
VIEW IN TELEGRAM



tg-me.com/hasanxdev/136
Create:
Last Update:

سوال جالبی از من پرسیده شد جهت افزایش دانش شما عزیزان به اشتراک گذاشتیم ❤️

🤔 سوال توسط amirmohammad Fathollahi پرسیده شد:
من برای api gateway دنبال best practice هستم با ocelot
هرچی ویدیو میبینم صرفا در حد اینه route کنه
ولی راجع به معماری و هندل کردن چندین پروژه حرفی نزدن
اگه کسی منبع خوب یا سمپل کد میشناسه معرفی کنه ممنون میشم
توی معماریش چه کار هایی میکنن چه چیز هایی رو بهش میسپرن
آیا صرفا فقط برای reverse ازش استفاده میکنن یا rate limiting و authentication هم بهش میسپرن
بیشتر سوالم راجع به معماریش هست


💡 جواب:
در واقع API Gateway رو یا باید خودمون پیاده سازی کنیم یا از ابزارهایی مثل Kong استفاده کنیم.
اگر خودمون پیاده سازی کنیم طبیعتاً دسترسی کامل به همه چیز داریم ولی Kong مثلا بهمون یک Dashboardهم میده و شاید در یک سری جاها به اندازه یک API Gateway اختصاصی دست آدم باز نباشه.

حالا وقتی میخواهی خودت پیاده کنی Per Environment باید Config های Routing خودت‌رو داشته باشی یعنی روی Develop با Production باید Configهاشون فرق داشته باشه چونکه آدرس ها در Develop Local و Production قطعا متفاوت هست.
یکی از Best Practiceهایی که معمولا در API Gateway ها در نظر می‌گیرند Code Less می‌کنندش یعنی هیچ کدی داخلش نمی‌گذارند و واقعاً شبیه Gateway عمل میکنه، بدون هیچ Business Logic خاصی.

درباره Rate limit باید بهتون بگم که Trade-off زیاد دارد!
یک موضوع infrastructure ای هست یعنی در لایه Application پیاده نمیشه چون Bottleneck برنامه میشه و اگر مشکل داشته باشه میتونه برنامه بندازه یا کند کنه همچنین میتونه single point of failure باشه.
پیچیدگی Rate Limit زمانی هست که چندین Instance از برنامه ما بالا باشه به همین دلیل Application Layer جای خوبی نیست براش اما اگر برنامه شما اینقدر کوچک هست که یک Instance فقط از API Gateway دارد، بنظرم دوباره فکر کنید آیا واقعاً به microservice نیاز داشتید یا نه!
حالا فرض میکنیم که شما به API Gateway نیاز داشتید و Rate Limit هم قرار هست پیاده کنید بنظر من بهتره در لایه Application خودتون پیاده سازی بشه و اگر واقعاً یک چیز نیاز دارید که خیلی Global باشه و زیرساخت ندارید مثل تیم DevOps بنظرم API Gateway جای خوبی هست

اما در کیس Authentication خیلی Trade-off نداریم!
کنترل رو می‌سپارن به خود Application ها، همان‌طور که گفتم خیلی سعی میشه API Gatewayها Code Less باشن فرض کنیم سرویس A با مدل AModel احراز هویت میشه و سرویس B با مدل BModel و این میتونه در API Gateway پیچیدگی ایجاد کنه و از نظر Separation of Concerns باید API Gateway یک Gateway بمونه واقعاً
به این دلیل که Authentication میتونه خیلی پیچیدگی ایجاد کنه من حداقل ندیدم جایی احراز هویت رو روی Gateway پیاده کنند، ولی این کار نشدنی نیست.
در بعضی از مدل های احراز هویت نیاز هست که Token برای سرویس اصلی که Authentication رو پیاده سازی کرده ارسال بشه و اگر ما در API Gateway احراز هویت رو پیاده سازی کرده باشیم این میتونه باعث بشه API Gateway خودش گلوگاه باشه که درخواست‌ها رو کند کنه و وقتی کندی در سیستم میبینیم نمی‌دانیم سرویس واقعاً مشکل دارد یا API Gateway

اگر نظری دارین در کامنت ها برام بنویسید 👇
Channel: @hasanxdev

BY Code With HSN


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/hasanxdev/136

View MORE
Open in Telegram


Code With HSN Telegram | DID YOU KNOW?

Date: |

For some time, Mr. Durov and a few dozen staffers had no fixed headquarters, but rather traveled the world, setting up shop in one city after another, he told the Journal in 2016. The company now has its operational base in Dubai, though it says it doesn’t keep servers there.Mr. Durov maintains a yearslong friendship from his VK days with actor and tech investor Jared Leto, with whom he shares an ascetic lifestyle that eschews meat and alcohol.

However, analysts are positive on the stock now. “We have seen a huge downside movement in the stock due to the central electricity regulatory commission’s (CERC) order that seems to be negative from 2014-15 onwards but we cannot take a linear negative view on the stock and further downside movement on the stock is unlikely. Currently stock is underpriced. Investors can bet on it for a longer horizon," said Vivek Gupta, director research at CapitalVia Global Research.

Code With HSN from us


Telegram Code With HSN
FROM USA